Spring面经[上]

什么是Spring框架

Spring 框架是一个用于构建企业级 Java 应用程序的开源框架。它提供了一种综合性的编程和配置模型，用于开发灵活、可扩展、可维护的应用程序。Spring 框架提供了许多功能和特性，帮助开发人员快速构建企业应用程序。

以下是 Spring 框架的一些核心特点：

轻量级：Spring 框架采用了松耦合的设计原则，仅依赖于少量的第三方库，因此它是一个轻量级的框架。开发人员可以根据需要选择使用 Spring 的特定功能，而无需引入整个框架。
控制反转（IoC）：Spring 框架通过控制反转（IoC）容器管理应用程序中的对象及其依赖关系。通过 IoC 容器，开发人员可以将对象的创建、组装和生命周期管理交给 Spring 框架处理，从而实现了松耦合和可测试性。
面向切面编程（AOP）：Spring 框架支持面向切面编程，可以通过 AOP 在应用程序中实现横切关注点的模块化。例如，日志记录、事务管理和安全性等横切关注点可以通过 AOP 进行集中处理，而不会侵入业务逻辑的代码。
声明式事务管理：Spring 框架提供了声明式事务管理的支持。通过使用注解或 XML 配置，开发人员可以将事务管理逻辑与业务逻辑分离，并且可以轻松地在方法或类级别上应用事务。
框架整合：Spring 框架可以与许多其他开源框架和技术无缝集成，如 Hibernate、MyBatis、JPA、Struts 和 JSF 等。这使得开发人员可以使用 Spring 框架来整合和协调不同的技术，构建全面的企业应用程序。
测试支持：Spring 框架提供了广泛的测试支持，包括单元测试和集成测试。它提供了一个专门的测试上下文，可以轻松地编写和执行单元测试，以验证应用程序的行为和功能。

总之，Spring 框架简化了企业级 Java 应用程序的开发过程，提供了一种模块化、可维护和可测试的编程模型，广泛应用于 Java 开发社区。

什么是IOC?

IoC（Inversion of Control，控制反转）是 Spring 框架的核心概念之一，它是一种设计原则和编程模式，用于实现松耦合和可测试的应用程序。在传统的编程模式中，对象之间的创建、组装和管理都是由开发人员手动完成的，而在 IoC 模式下，这些责任被委托给一个容器来管理。

在 IoC 模式中，对象之间的依赖关系被反转了，即由开发人员手动控制对象之间的依赖关系变为由容器自动注入依赖。这种反转的控制使得应用程序的各个模块之间解耦，提高了代码的灵活性、可维护性和可测试性。

IoC 的实现依赖于一个称为 IoC 容器的组件。IoC 容器负责创建和管理对象，以及解决对象之间的依赖关系。开发人员只需在配置文件（如 XML 配置文件）或使用注解方式中指定对象的依赖关系和其他配置细节，容器就会根据这些配置信息动态地实例化对象、注入依赖并管理对象的生命周期。

实现手段

IoC 容器通过以下两种主要的方式来实现控制反转：

依赖注入（Dependency Injection，DI）：依赖注入是 IoC 的一种具体实现方式，通过将依赖关系注入到对象中，实现了对象之间的解耦。容器负责查找依赖对象，并将其自动注入到相应的对象中。依赖注入可以通过构造函数、Setter 方法或接口注入来完成。
依赖查找（Dependency Lookup）：依赖查找是另一种 IoC 的实现方式，它通过容器提供的 API，开发人员手动查找和获取所需的依赖对象。开发人员在代码中通过容器提供的接口来获取所需的对象实例，从而实现了对象之间的解耦。

优点分析

相比于传统的程序开发，使用 IoC 的好处在于：

降低了代码之间的耦合度，使程序变得简单。
可维护性好，对象更易扩展和重用。
IoC 容器管理对象，简化开发难度，节省开发时间。

总之，IoC 是 Spring 框架的基石，是 Spring 框架众多特性的基础。

依赖注入和依赖查找有什么区别?

依赖注入和依赖查找都是实现 IoC 的两种常用方法，它们的区别如下。

依赖注入

依赖注入是一种将依赖关系从一个对象传递到另一个对象的技术。在依赖注入中，对象不再负责创建或查找它所依赖的对象，而是将依赖关系委托给 IoC 容器。容器在创建对象时，自动将依赖的对象注入到它所依赖的对象中。

依赖注入的优点是可以减少对象之间的耦合，使代码更加灵活和可维护。在 Spring 框架中，依赖注入通过注解或 XML 配置文件来实现。

依赖查找

依赖查找是一种从 IoC 容器中查找依赖对象的技术。在依赖查找中，对象负责查找它所依赖的对象，而不是将依赖关系委托给容器。容器只负责管理对象的生命周期，而不负责对象之间的依赖关系。

依赖查找的优点是可以更加精细地控制对象之间的依赖关系，但是它也会增加对象之间的耦合度。在 Spring 框架中，依赖查找通过 ApplicationContext 接口的 getBean() 方法来实现。

小结

因此，依赖注入和依赖查找的区别在于，依赖注入是将依赖关系委托给容器，由容器来管理对象之间的依赖关系；而依赖查找是由对象自己来查找它所依赖的对象，容器只负责管理对象的生命周期。

依赖注入和依赖查找?

依赖注入和依赖查找都是实现 IoC 的两种常用方法，它们的区别如下。

依赖注入

依赖注入的优点是可以减少对象之间的耦合，使代码更加灵活和可维护。在 Spring 框架中，依赖注入通过注解或 XML 配置文件来实现。

依赖查找

依赖查找的优点是可以更加精细地控制对象之间的依赖关系，但是它也会增加对象之间的耦合度。在 Spring 框架中，依赖查找通过 ApplicationContext 接口的 getBean() 方法来实现。

IoC和DI有什么区别?

IoC和DI都是Spring框架中的核心概念，他们的区别在于：

IoC (控制反转)：它是一种思想，主要解决程序设计中的对象依赖关系管理问题。在 IoC 思想中，对象的创建权反转给第三方容器，由容器进行对象的创建及依赖关系的管理。
DI（Dependency Injection，依赖注入）：它是 IoC 思想的具体实现方式之一，用于实现 IoC。在 Spring 中，依赖注入是指:在对象创建时，由容器自动将依赖对象注入到需要依赖的对象中。

简单来说，它们的关系是：

IoC 是一种思想、理念，定义了对象创建和依赖关系处理的方式。
DI 是 IoC 思想的具体实现方式之一，实际提供对象依赖关系的注入功能。

所以 IoC 是更基础和广义的概念，DI 可以说是 IoC 的一种实现手段。大多数情况下，我们提到 IoC 的时候，其实意味着 DI，因为 DI 已经是 IoC 最常见和广泛使用的实现方式了。

例如在 Spring 框架中：

IoC 体现为 Spring 容器承担了对象创建及依赖关系管理的控制权。
DI 体现为 Spring 容器通过构造方法注入、Setter 方法注入等方式，将依赖对象注入到需要依赖的对象中。

所以综上，IoC 和 DI 之间的关系可以这样理解:

IoC 是理论，DI 是实践。
IoC 是思想，DI 是手段。
IoC 是整体，DI 是部分。

Bean有几种作用域

在 Spring 中，Bean 的作用域指的是 Bean 实例的生命周期和可见范围。

Spring 中的 Bean 作用域主要有以下几种：

singleton

singleton 是 Spring 中默认的 Bean 作用域，它表示在整个应用程序中只存在一个 Bean 实例。每次请求该 Bean 时，都会返回同一个实例。

prototype

prototype 表示每次请求该 Bean 时都会创建一个新的实例。每个实例都有自己的属性值和状态，因此它们之间是相互独立的。

request

request 表示在一次 HTTP 请求中只存在一个 Bean 实例。在同一个请求中，多次请求该 Bean 时都会返回同一个实例。不同的请求之间，该 Bean 的实例是相互独立的。

session

session 表示在一个 HTTP Session 中只存在一个 Bean 实例。在同一个 Session 中，多次请求该 Bean 时都会返回同一个实例。不同的 Session 之间，该 Bean 的实例是相互独立的。

application

application 表示在一个 ServletContext 中只存在一个 Bean 实例。该作用域只在 Spring ApplicationContext 上下文中有效。

websocket

websocket 表示在一个 WebSocket 中只存在一个 Bean 实例。该作用域只在 Spring ApplicationContext 上下文中有效。

参考文档

Spring 官方文档：https://docs.spring.io/spring-framework/docs/5.3.x/reference/html/core.html#beans-factory-scopes

什么是AOP

AOP（Aspect-Oriented Programming，面向切面编程）是一种软件开发的编程范式，用于将跨越多个模块的（横切）关注点从核心业务逻辑中分离出来，使得横切关注点的定义和应用能够更加集中和重用。

在传统的面向对象编程中，程序的功能逻辑被分散在各个对象中，而横切关注点（如日志记录、事务管理、安全控制等）则分散在多个对象之间，导致代码重复、可维护性差，并且难以修改和扩展。AOP 的目标就是解决这些问题。

AOP 通过引入横切关注点，将其与核心业务逻辑分离，并以模块化的方式进行管理。它通过切面（Aspect）来描述横切关注点，切面是对横切关注点的封装。切面定义了在何处、何时和如何应用横切关注点。在 AOP 中，切面可以横跨多个对象，独立于核心业务逻辑。

AOP组成

AOP 的实现依赖于以下几个概念：

切面（Aspect）：切面是横切关注点的模块化单元，它将通知和切点组合在一起，描述了在何处、何时和如何应用横切关注点。
切点（Pointcut）：用于定义哪些连接点被切面关注，即切面要织入的具体位置。
连接点（Join Point）：在程序执行过程中的某个特定点，例如方法调用、异常抛出等。
通知（Advice）：切面在特定切点上执行的代码，包括在连接点之前、之后或周围执行的行为。
织入（Weaving）：将切面应用到目标对象中的过程，可以在编译时、加载时或运行时进行。

优点分析

AOP 的优点是可以将横切关注点从应用程序的核心业务逻辑中分离出来，以便更好地实现模块化和复用。通过使用 AOP，可以将通用的功能（如日志记录、性能统计、事务管理等）封装成切面，然后在需要的地方进行重用，从而提高代码的可维护性和可重用性。

说说AOP技术实现原理?

AOP（Aspect-Oriented Programming，面向切面编程）是一种编程技术，它允许开发者在不改变现有代码的情况下，增加新的功能或行为，这些功能或行为被称为“切面”。

AOP 可以通过预编译方式和运行期动态代理的方式来实现，它的主要目的是降低业务逻辑的耦合性，提高程序的可重用性和开发效率。

AOP 常用于统一功能的处理，例如：事务管理、日志记录、权限检查等功能。

AOP优点分析

使用 AOP 的主要原因有以下几点：

模块化：通过将公共行为（如日志记录、事务管理）提取为独立的切面，可以使代码更加模块化，提高代码的可维护性和可读性。
减少重复代码：通过使用 AOP，可以将重复的代码（如日志记录、权限检查）提取到一个切面中，避免在多个地方重复编写相同的代码。
解耦：AOP 允许开发者将业务逻辑与横切关注点（如日志记录、事务管理）分离，从而降低业务逻辑的耦合性，提高程序的可重用性和可扩展性。

AOP技术实现

AOP 实现技术主要分为两大类：静态代理和动态代理。

静态代理：通过 AOP 框架提供的命令进行编译，从而在编译阶段生成 AOP 代理类。这种方式也被称为编译时增强。静态代理包括编译时编织和类加载时编织两种方式。
动态代理：在运行时在内存中“临时”生成 AOP 动态代理类，因此也被称为运行时增强。
动态代理主要有两种实现方式：
1. JDK 动态代理：JDK 动态代理要求被代理的类必须实现一个接口，它通过反射来接收被代理的类，并使用 InvocationHandler 接口和 Proxy 类实现代理。
2. CGLIB 动态代理：CGLIB 则是一个代码生成的类库，它可以在运行时动态地生成某个类的子类，通过继承的方式实现代理。如果目标类没有实现接口，Spring AOP 会选择使用 CGLIB 来动态代理目标类。

AOP实现原理

Spring AOP（面向切面编程）的实现原理主要基于动态代理技术，它提供了对业务逻辑各个方面的关注点分离和模块化，使得非功能性需求（如日志记录、事务管理、安全检查等）可以集中管理和维护，而不是分散在各个业务模块中。

Spring AOP 实现原理的关键要点如下：

代理机制：
- JDK 动态代理：对于实现了接口的目标类，Spring AOP 默认使用 JDK 的 java.lang.reflect.Proxy 类来创建代理对象。代理对象会在运行时实现代理接口，并覆盖其中的方法，在方法调用前后执行切面逻辑（即通知，advice）。
- CGLIB 动态代理：对于未实现接口的类，Spring AOP 会选择使用 CGLIB 库来生成代理对象。CGLIB 通过字节码技术创建目标类的子类，在子类中重写目标方法并在方法调用前后插入切面逻辑。
关键概念：
- 切面（Aspect）：切面是一个包含了横切关注点声明的模块化单元，它可以有多个切入点和通知组成。
- 切入点（Pointcut）：切入点定义了匹配通知应该被织入的方法或方法执行点的规则表达式。
- 通知（Advice）：通知是在特定切入点处执行的代码片段，分为多种类型，如前置通知（Before advice）、后置通知（After returning advice）、异常后通知（After throwing advice）、最终通知（After (finally) advice）以及环绕通知（Around advice）。
织入（Weaving）：织入是指将切面应用到目标对象来创建一个新的代理对象的过程。在 Spring AOP 中，织入发生在运行时，通过代理对象的方式实现。
代理工厂：Spring 内部通过 ProxyFactory 或相关的 AOP 基础设施（如 Advisor、AdvisorChainFactory 等）来创建和管理代理对象。
执行流程：当客户端通过代理对象调用目标方法时，代理对象会拦截这个调用，根据切面配置找到对应的通知，并按照通知类型的不同执行相应的增强逻辑。例如，如果是环绕通知，它会完全控制原始方法的调用过程，可以在调用前后插入自定义逻辑，甚至决定是否执行原方法。

通过上述方式，Spring AOP 巧妙地实现了对目标对象方法的拦截和增强，从而实现了面向切面编程的功能。

JDK动态代理和CGLIB有什么区别?

JDK动态代理和CGLIB动态代理都是常见的动态代理实现技术，但它们有以下区别：

JDK 动态代理基于接口，要求目标对象实现接口；CGLIB 动态代理基于类，可以代理没有实现接口的目标对象。
JDK 动态代理使用 java.lang.reflect.Proxy 和 java.lang.reflect.InvocationHandler 来生成代理对象；CGLIB 动态代理使用 CGLIB 库来生成代理对象。
JDK 动态代理生成的代理对象是目标对象的接口实现；CGLIB 动态代理生成的代理对象是目标对象的子类。
JDK 动态代理性能相对较高，生成代理对象速度较快；CGLIB 动态代理性能相对较低，生成代理对象速度较慢。
CGLIB 动态代理无法代理 final 类和 final 方法；JDK 动态代理可以代理任意类。

PS：在 Spring 框架中，即使用了 JDK 动态代理又使用 CGLIB，默认情况下使用的是 JDK 动态代理，但是如果目标对象没有实现接口，则会使用 CGLIB 动态代理。

简单来说，JDK 动态代理要求被代理类实现接口，而 CGLIB 要求被代理类不能是 final 修饰的最终类，在 JDK 8 以上的版本中，因为 JDK 动态代理做了专门的优化，所以它的性能要比 CGLIB 高。

动态代理是如何实现的?

动态代理是一种在运行时动态生成代理类的代理方式。动态代理的常用实现方法有以下两种。

JDK动态代理

JDK 动态代理是一种使用 Java 标准库中的 java.lang.reflect.Proxy 类来实现动态代理的技术。在 JDK 动态代理中，被代理类必须实现一个或多个接口，并通过 InvocationHandler 接口来实现代理类的具体逻辑。

具体来说，当使用 JDK 动态代理时，需要定义一个实现 InvocationHandler 接口的类，并在该类中实现代理类的具体逻辑。然后，通过 Proxy.newProxyInstance() 方法来创建代理类的实例。该方法接受三个参数：类加载器、代理类要实现的接口列表和 InvocationHandler 对象，如下代码所示：

java

import org.example.demo.service.AliPayService;
import org.example.demo.service.PayService;

import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;

//动态代理：使用JDK提供的api（InvocationHandler、Proxy实现），此种方式实现，要求被代理类必须实现接口
public class PayServiceJDKInvocationHandler implements InvocationHandler {
    
    //目标对象即就是被代理对象
    private Object target;
    
    public PayServiceJDKInvocationHandler( Object target) {
        this.target = target;
    }
    
    //proxy代理对象
    @Override
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        //1.安全检查
        System.out.println("安全检查");
        //2.记录日志
        System.out.println("记录日志");
        //3.时间统计开始
        System.out.println("记录开始时间");

        //通过反射调用被代理类的方法
        Object retVal = method.invoke(target, args);

        //4.时间统计结束
        System.out.println("记录结束时间");
        return retVal;
    }

    public static void main(String[] args) {

        PayService target=  new AliPayService();
        //方法调用处理器
        InvocationHandler handler = 
            new PayServiceJDKInvocationHandler(target);
        //创建一个代理类：通过被代理类、被代理实现的接口、方法调用处理器来创建
        PayService proxy = (PayService) Proxy.newProxyInstance(
                target.getClass().getClassLoader(),
                new Class[]{PayService.class},
                handler
        );
        proxy.pay();
    }
}

JDK 动态代理的优点是实现简单，易于理解和掌握，但是它的缺点是只能代理实现了接口的类，无法代理没有实现接口的类。

CGLIB动态代理

CGLIB 动态代理是一种使用 CGLIB 库来实现动态代理的技术。在 CGLIB 动态代理中，代理类不需要实现接口，而是通过继承被代理类来实现代理。具体来说，当使用 CGLIB 动态代理时，需要定义一个继承被代理类的子类，并在该子类中实现代理类的具体逻辑。然后，通过 Enhancer.create() 方法来创建代理类的实例。该方法接受一个类作为参数，表示要代理的类，如下代码所示：

java

import org.springframework.cglib.proxy.Enhancer;
import org.springframework.cglib.proxy.MethodInterceptor;
import org.springframework.cglib.proxy.MethodProxy;
import org.example.demo.service.AliPayService;
import org.example.demo.service.PayService;

import java.lang.reflect.Method;

public class PayServiceCGLIBInterceptor implements MethodInterceptor {

    //被代理对象
    private Object target;
    
    public PayServiceCGLIBInterceptor(Object target){
        this.target = target;
    }
    
    @Override
    public Object intercept(Object o, Method method, Object[] args, MethodProxy methodProxy) throws Throwable {
        //1.安全检查
        System.out.println("安全检查");
        //2.记录日志
        System.out.println("记录日志");
        //3.时间统计开始
        System.out.println("记录开始时间");

        //通过cglib的代理方法调用
        Object retVal = methodProxy.invoke(target, args);

        //4.时间统计结束
        System.out.println("记录结束时间");
        return retVal;
    }
    
    public static void main(String[] args) {
        PayService target=  new AliPayService();
        PayService proxy= (PayService) Enhancer.create(target.getClass(),new PayServiceCGLIBInterceptor(target));
        proxy.pay();
    }
}

CGLIB 动态代理的优点是可以代理没有实现接口的类，但是它的缺点是实现相对复杂，需要了解 CGLIB 库的使用方法。

小结

综上所述，动态代理的实现方法主要有 JDK 动态代理和 CGLIB 动态代理。JDK 动态代理中，代理类必须实现一个或多个接口，而 CGLIB 动态代理中，代理类不需要实现接口，但代理类不能是 final 类型，因为它是通过定义一个被代理类的子类来实现动态代理的，因此开发者需要根据具体的需求选择合适的技术来实现动态代理

@Configuration与@Component区别?

一句话概括就是 @Configuration 中所有带 @Bean 注解的方法都会被动态代理，因此调用该方法返回的都是同一个实例。

理解：调用@Configuration类中的@Bean注解的方法，返回的是同一个示例；而调用@Component类中的@Bean注解的方法，返回的是一个新的实例。

@Configuration修饰的类会被Cglib动态代理，在类内部方法相互调用添加了@Bean注解的方法时通过在切面方法中调用getBean()方法来保证调用该方法返回的都是同一个实例
@Component修饰的类不会被代理，每次方法内部调用都会生成新的实例，这样就不能保证其生成的对象是一个单例对象。

@Transactional失效的原因
@Transactional可以JDK或Cglib动态代理实现的事务（默认JDK），在Bean创建时如果检测到类中有@Transactional就会对其进行动态代理，如果类内部没有被@Transactional修饰的方法中调用了其它被@Transactional修饰的内部方法，那么此时事务注解是不会生效的，原因在于只有外部调用才会走代理增强逻辑而内部类的互相调用只是原对象的方法调用，没有经过代理类。

其实上面可以看出出Spring在使用两种代理方式时的不同处理：@Configuration修饰的类被Cglib动态代理后，类内部方法调用也可以走增强逻辑，而含有@Transactional注解的类无论是Cglib还是JDK动态代理都不能进行方法内部的相互调用。

@Configuration

java

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented@Component
public @interface Configuration {
    String value() default "";
}

从定义来看， @Configuration注解本质上还是@Component，因此或者 @ComponentScan 都能处理@Configuration注解的类。

@Configuration标记的类必须符合下面的要求：

配置类必须以类的形式提供（不能是工厂方法返回的实例），允许通过生成子类在运行时增强（cglib 动态代理）。
配置类不能是final 类（没法动态代理）。
配置注解通常为了通过 @Bean注解生成 Spring 容器管理的类，
配置类必须是非本地的（即不能在方法中声明，不能是 private）。
任何嵌套配置类都必须声明为static。
@Bean方法可能不会反过来创建进一步的配置类（也就是返回的 bean 如果带有 @Configuration，也不会被特殊处理，只会作为普通的 bean）。

java

@Configuration
public class MyBeanConfig {
    @Bean 
    public Country country () {
        return new Country();
    }
    
    @Bean
    public UserInfo userInfo() {
        return new UserInfo(counrtry());
    }

}

相信大多数人第一次看到上面 userInfo() 中调用 country()时，会认为这里的 Country和上面 @Bean方法返回的 Country 可能不是同一个对象，因此可能会通过下面的方式来替代这种方式：

java

@Autowired

private Country country;

实际上不需要这么做（后面会给出需要这样做的场景），直接调用country() 方法返回的是同一个实例。

有些特殊情况下，我们不希望 MyBeanConfig被代理（代理后会变成WebMvcConfig$$EnhancerBySpringCGLIB$$8bef3235293）时，就得用 @Component，这种情况下，上面的写法就需要改成下面这样：

java

@Component
public class MyBeanConfig {
    @Autowired
    private Country country;
    
    @Bean
    public Country country(){
        return new Country();
    }
    
    @Bean 
    public UserInfo userInfo(){
        return new UserInfo(country);
    }
}

这种方式可以保证使用的同一个 Country 实例。

JDK动态代理和CGLIB有什么区别?

JDK 动态代理和 CGLIB 动态代理都是常见的动态代理实现技术，但它们有以下区别：

JDK 动态代理基于接口，要求目标对象实现接口；CGLIB 动态代理基于类，可以代理没有实现接口的目标对象。
JDK 动态代理使用 java.lang.reflect.Proxy 和 java.lang.reflect.InvocationHandler 来生成代理对象；CGLIB 动态代理使用 CGLIB 库来生成代理对象。
JDK 动态代理生成的代理对象是目标对象的接口实现；CGLIB 动态代理生成的代理对象是目标对象的子类。
JDK 动态代理性能相对较高，生成代理对象速度较快；CGLIB 动态代理性能相对较低，生成代理对象速度较慢。
CGLIB 动态代理无法代理 final 类和 final 方法；JDK 动态代理可以代理任意类。

PS：在 Spring 框架中，即使用了 JDK 动态代理又使用 CGLIB，默认情况下使用的是 JDK 动态代理，但是如果目标对象没有实现接口，则会使用 CGLIB 动态代理。

单例Bean线程安全吗?

无状态的单例 Bean 是线程安全的，而有状态的单例 Bean 是非线程安全的，所以总的来说单例 Bean 还是非线程安全的。

什么是有状态和无状态？

有状态的 Bean 是指 Bean 中包含了状态，比如成员变量，而无状态的 Bean 是指 Bean 中不包含状态，比如没有成员变量，或者成员变量都是 final 的。

为什么非线程安全？

Spring 默认的 Bean 是单例模式，意味着容器中只有一个 Bean 实例，所有的线程都会使用并操作这个唯一的 Bean 实例，那么多个线程同时调用修改这个单例 Bean，就会产生线程安全问题。举个例子：

java

@Component
public class SingletonBean {
    private int counter = 0;

    public int getCounter() {
        return counter++; 
    }
}

这是一个简单的单例 Bean，有一个计数器，每调用一次加 1，当多个线程同时调用这个 Bean 的 getCounter() 方法时，因为 counter++ 是非原子性操作（先查询再加等），所以最终的结果就会比实际的加等次数少，这就是线程安全问题。

如何保证线程安全？

Spring 中保证单例 Bean 线程安全的手段有以下几个：

变为原型 Bean：在 Bean 上添加 @Scope("prototype") 注解，将其变为多例 Bean。这样每次注入时返回一个新的实例，避免竞争。
加锁：在 Bean 中对需要同步的方法或代码块添加同步锁 @Synchronized 或使用 Java 中的线程同步工具 ReentrantLock 等。
使用线程安全的集合：如 Vector、Hashtable 代替 ArrayList、HashMap 等非线程安全集合。
变为无状态 Bean：不在 Bean 中保存状态，让 Bean 成为无状态 Bean。无状态的 Bean 没有共享变量，自然也无须考虑线程安全问题。
使用线程局部变量 ThreadLocal：在方法内部使用线程局部变量 ThreadLocal，因为 ThreadLocal 是线程独享的，所以也不存在线程安全问题。

单例Bean线程一定不安全吗?

默认情况下，Spring Boot 中的 Bean 是非线程安全的。这是因为，默认情况下 Bean 的作用域是单例模式，那么此时，所有的请求都会共享同一个 Bean 实例，这意味着这个 Bean 实例，在多线程下可能被同时修改，那么此时它就会出现线程安全问题。

Bean 的作用域（Scope）指的是确定在应用程序中创建和管理 Bean 实例的范围。也就是在 Spring 中，可以通过指定不同的作用域来控制 Bean 实例的生命周期和可见性。例如，单例模式就是所有线程可见并共享的，而原型模式则是每次请求都创建一个新的原型对象。

并不是，单例 Bean 分为以下两种类型：

无状态 Bean（线程安全）：Bean 没有成员变量，或多线程只会对 Bean 成员变量进行查询操作，不会修改操作。
有状态 Bean（非线程安全）：Bean 有成员变量，并且并发线程会对成员变量进行修改操作。

所以说：有状态的单例 Bean 是非线程安全的，而无状态的 Bean 是线程安全的。

但在程序中，只要有一种情况会出现线程安全问题，那么它的整体就是非线程安全的，所以总的来说，单例 Bean 还是非线程安全的。

① 无状态的Bean

无状态的 Bean 指的是不存在成员变量，或只有查询操作，没有修改操作，它的实现示例代码如下：

java

import org.springframework.stereotype.Service;

@Service
public class StatelessService {
    public void doSomeTask() {
        // 执行任务
    }
}

② 有状态的Bean

有成员变量，并且存在对成员变量的修改操作，如下代码所示：

java

import org.springframework.stereotype.Service;

@Service
public class UserService {
    private int count = 0;
    public void incrementCount() {
        count++; // 非原子操作，并发存在线程安全问题
    }
    public int getCount() {
        return count;
    }
}

如何保证线程安全

想要保证有状态 Bean 的线程安全，可以从以下几个方面来实现：

使用 ThreadLocal（线程本地变量）：每个线程修改自己的变量，就没有线程安全问题了。
使用锁机制：例如 synchronized 或 ReentrantLock 加锁修改操作，保证线程安全。
设置 Bean 为原型作用域（Prototype）：将 Bean 的作用域设置为原型，这意味着每次请求该 Bean 时都会创建一个新的实例，这样可以防止不同线程之间的数据冲突，不过这种方法增加了内存消耗。
使用线程安全容器：例如使用 Atomic 家族下的类（如 AtomicInteger）来保证线程安全，此实现方式的本质还是通过锁机制来保证线程安全的，Atomic 家族底层是通过乐观锁 CAS（Compare And Swap，比较并替换）来保证线程安全的。

使用ThreadLocal保证线程安全

java

import org.springframework.stereotype.Service;

@Service
public class UserService {
    private ThreadLocal<Integer> count = ThreadLocal.withInitial(() -> 0);

    public void incrementCount() {
        count.set(count.get() + 1);
    }

    public int getCount() {
        return count.get();
    }
}

使用 ThreadLocal 需要注意一个问题，在用完之后记得调用 ThreadLocal 的 remove 方法，不然会发生内存泄漏问题。

使用锁机制

锁机制中最简单的是使用 synchronized 修饰方法，让多线程执行此方法时排队执行，这样就不会有线程安全问题了，如下代码所示：

java

import org.springframework.stereotype.Service;

@Service
public class UserService {
    private int count = 0;
    public synchronized void incrementCount() {
        count++; // 非原子操作，并发存在线程安全问题
    }
    public int getCount() {
        return count;
    }
}

设置为原型作用域

原型作用域通过 @Scope("prototype") 来设置，表示每次请求时都会生成一个新对象（也就没有线程安全问题了），如下代码所示：

java

import org.springframework.stereotype.Service;

@Service
@Scope("prototype")
public class UserService {
    private int count = 0;
    public void incrementCount() {
        count++; // 非原子操作，并发存在线程安全问题
    }
    public int getCount() {
        return count;
    }
}

使用线程安全容器

我们可以使用线程安全的容器，例如 AtomicInteger 来替代 int，从而保证线程安全，如下代码所示：

java

import org.springframework.stereotype.Service;
import java.util.concurrent.atomic.AtomicInteger;

@Service
public class UserService {

    private AtomicInteger count = new AtomicInteger(0);

    public void incrementCount() {
        count.incrementAndGet();
    }

    public int getCount() {
        return count.get();
    }
}

实际工作中，通常会根据具体的业务场景来选择合适的线程安全方案，但是以上解决线程安全的方案中，ThreadLocal 和原型作用域会使用更多的资源，占用更多的空间来保证线程安全，所以在使用时通常不会作为最佳考虑方案。

而锁机制和线程安全的容器通常会优先考虑，但需要注意的是 AtomicInteger 底层是乐观锁 CAS 实现的，因此它存在乐观锁的典型问题 ABA 问题（如果有状态的 Bean 中既有 ++ 操作，又有 -- 操作时，可能会出现 ABA 问题），此时就要使用锁机制，或 AtomicStampedReference 来解决 ABA 问题了。

Bean有几种注入方式?

在 Spring 中实现依赖注入的常见方式有以下 3 种：

属性注入（Field Injection）；
Setter 注入（Setter Injection）；
构造方法注入（Constructor Injection）。
接口注入（Interface Injection） [Spring目前不支持]

它们的具体使用和优缺点分析如下。

属性注入

属性注入是我们最熟悉，也是日常开发中使用最多的一种注入方式，它的实现代码如下：

java

@RestController
public class UserController {
    // 属性对象
    @Autowired
    private UserService userService;

    @RequestMapping("/add")
    public UserInfo add(String username, String password) {
        return userService.add(username, password);
    }
}

属性注入最大的优点就是实现简单、使用简单，只需要给变量上添加一个注解（@Autowired），就可以在不 new 对象的情况下，直接获得注入的对象了（这就是 DI 的功能和魅力所在），所以它的优点就是使用简单。

然而，属性注入虽然使用简单，但也存在着很多问题，甚至编译器 Idea 都会提醒你“不建议使用此注入方式”，Idea 的提示信息如下：

属性注入的缺点主要包含以下 3 个：

功能性问题：无法注入一个不可变的对象（final 修饰的对象）；
通用性问题：只能适应于 IoC 容器；
设计原则问题：更容易违背单一设计原则。

接下来我们一一来看。

功能性问题

使用属性注入无法注入一个不可变的对象（final 修饰的对象），如下图所示：

原因也很简单：在 Java 中 final 对象（不可变）要么直接赋值，要么在构造方法中赋值，所以当使用属性注入 final 对象时，它不符合 Java 中 final 的使用规范，所以就不能注入成功了。

通用性问题

使用属性注入的方式只适用于 IoC 框架（容器），如果将属性注入的代码移植到其他非 IoC 的框架中，那么代码就无效了，所以属性注入的通用性不是很好。

设计原则问题

使用属性注入的方式，因为使用起来很简单，所以开发者很容易在一个类中同时注入多个对象，而这些对象的注入是否有必要？是否符合程序设计中的单一职责原则？就变成了一个问题。但可以肯定的是，注入实现越简单，那么滥用它的概率也越大，所以出现违背单一职责原则的概率也越大。注意：这里强调的是违背设计原则（单一职责）的可能性，而不是一定会违背设计原则，二者有着本质的区别

setter注入

Setter 注入的实现代码如下：

java

@RestController
public class UserController {
    // Setter 注入
    private UserService userService;

    @Autowired
    public void setUserService(UserService userService) {
        this.userService = userService;
    }

    @RequestMapping("/add")
    public UserInfo add(String username, String password) {
        return userService.add(username, password);
    }
}

从上面代码可以看出，Setter 注入比属性注入要麻烦很多。 要说 Setter 注入有什么优点的话，那么首当其冲的就是它完全符合单一职责的设计原则，因为每一个 Setter 只针对一个对象。但它的缺点也很明显，它的缺点主要体现在以下 2 点：

不能注入不可变对象（final 修饰的对象）；
注入的对象可被修改。

使用 Setter 注入依然不能注入不可变对象，比如以下注入会报错：

注入的对象可被修改

Setter 注入提供了 setXXX 的方法，意味着你可以在任何时候、在任何地方，通过调用 setXXX 的方法来改变注入对象，所以 Setter 注入的问题是，被注入的对象可能随时被修改。

构造方法注入

构造方法注入是 Spring 官方从 4.x 之后推荐的注入方式，它的实现代码如下：

java

@RestController
public class UserController {
    // 构造方法注入
    private UserService userService;

    @Autowired
    public UserController(UserService userService) {
        this.userService = userService;
    }

    @RequestMapping("/add")
    public UserInfo add(String username, String password) {
        return userService.add(username, password);
    }
}

当然，如果当前的类中只有一个构造方法，那么 @Autowired 也可以省略，所以以上代码还可以这样写：

java

@RestController
public class UserController {
    // 构造方法注入
    private UserService userService;

    public UserController(UserService userService) {
        this.userService = userService;
    }

    @RequestMapping("/add")
    public UserInfo add(String username, String password) {
        return userService.add(username, password);
    }
}

构造方法注入相比于前两种注入方法，它可以注入不可变对象，并且它只会执行一次，也不存在像 Setter 注入那样，被注入的对象随时被修改的情况，它的优点有以下 4 个：

可注入不可变对象；
注入对象不会被修改；
注入对象会被完全初始化；
通用性更好。

注入不可变对象

使用构造方法注入可以注入不可变对象，如下代码所示：

注入对象不会被修改

构造方法注入不会像 Setter 注入那样，构造方法在对象创建时只会执行一次，因此它不存在注入对象被随时（调用）修改的情况。

完全初始化

因为依赖对象是在构造方法中执行的，而构造方法是在对象创建之初执行的，因此被注入的对象在使用之前，会被完全初始化，这也是构造方法注入的优点之一。

通用性更好

构造方法和属性注入不同，构造方法注入可适用于任何环境，无论是 IoC 框架还是非 IoC 框架，构造方法注入的代码都是通用的，所以它的通用性更好。

接口注入

通过接口将依赖项传递给对象。依赖项的消费者实现一个接口，该接口包含一个设置依赖项的方法。这种方式较少使用，因为它需要依赖项的消费者实现额外的接口。

java

public interface RepositoryAware {
    void setRepository(Repository repository);
}

public class Service implements RepositoryAware {
    private Repository repository;

    // 接口注入
    @Override
    public void setRepository(Repository repository) {
        this.repository = repository;
    }

    public void performService() {
        repository.doSomething();
    }
}

依赖注入的常见实现方式有 3 种：属性注入、Setter 注入和构造方法注入。其中属性注入的写法最简单，所以日常项目中使用的频率最高，但它的通用性不好；而 Spring 官方推荐的是构造方法注入，它可以注入不可变对象，其通用性也更好，如果是注入可变对象，那么可以考虑使用 Setter 注入。

@Autowired底层是如何实现的?

@Autowired 是 Spring 框架中常用的注解之一，它可以自动装配 Bean，使得开发人员可以更加方便地使用 Spring 框架，但 @Autowired 底层是如何实现的呢？

Spring 中的 @Autowired 注解是通过依赖注入（DI）实现的，依赖注入是一种设计模式，它将对象的创建和依赖关系的管理从应用程序代码中分离出来，使得应用程序更加灵活和可维护。

具体来说，当 Spring 容器启动时，它会扫描应用程序中的所有 Bean，并将它们存储在一个 BeanFactory 中。当应用程序需要使用某个 Bean 时，Spring 容器会自动将该 Bean 注入到应用程序中。

但再往底层说，DI 是通过 Java 反射机制实现的。具体来说，当 Spring 容器需要注入某个 Bean 时，它会使用 Java 反射机制来查找符合条件的 Bean，并将其注入到应用程序中。

所以说，@Autowired 注解是通过 DI 的方式，底层通过 Java 的反射机制来实现的。

@Autowired和@Resource有什么区别?

在 Spring 中，@Autowired 和 @Resource 都是用于注入 Bean 对象的注解。它们的作用类似，但是有以下几点区别。

来源不同

@Autowired 和 @Resource 来自不同的“父类”，其中 @Autowired 是 Spring 定义的注解，而 @Resource 是 Java 定义的注解，它来自于 JSR-250（Java 250 规范提案）。

小知识：JSR 是 Java Specification Requests 的缩写，意思是“Java 规范提案”。任何人都可以提交 JSR 给 Java 官方，但只有最终确定的 JSR，才会以 JSR-XXX 的格式发布，如 JSR-250，而被发布的 JSR 就可以看作是 Java 语言的规范或标准。

依赖查找顺序不同

依赖注入的功能，是通过先在 Spring IoC 容器中查找对象，再将对象注入引入到当前类中。而查找有分为两种实现：按名称（byName）查找或按类型（byType）查找，其中 @Autowired 和 @Resource 都是既使用了名称查找又使用了类型查找，但二者进行查找的顺序却截然相反。

@Autowired查找顺序

@Autowired 是先根据类型（byType）查找，如果存在多个 Bean 再根据名称（byName）进行查找，它的具体查找流程如下：

关于以上流程，可以通过查看 Spring 源码中的 org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor#postProcessPropertyValues 实现分析得出，源码执行流程如下图所示：

@Resource查找顺序

@Resource 是先根据名称查找，如果（根据名称）查找不到，再根据类型进行查找，它的具体流程如下图所示：

关于以上流程可以在 Spring 源码的 org.springframework.context.annotation.CommonAnnotationBeanPostProcessor#postProcessPropertyValues 中分析得出。虽然 @Resource 是 JSR-250 定义的，但是由 Spring 提供了具体实现，它的源码实现如下：

由上面的分析可以得出：

@Autowired 先根据类型（byType）查找，如果存在多个（Bean）再根据名称（byName）进行查找；
@Resource 先根据名称（byName）查找，如果（根据名称）查找不到，再根据类型（byType）进行查找。

@Autowired 和 @Resource 在使用时都可以设置参数，比如给 @Resource 注解设置 name 和 type 参数，实现代码如下：

java

@Resource(name = "userinfo", type = UserInfo.class)
private UserInfo user;

但二者支持的参数以及参数的个数完全不同，其中 @Autowired 只支持设置一个 required 的参数，而 @Resource 支持 7 个参数，支持的参数如下图所示：

依赖注入的支持不同

@Autowired 和 @Resource 支持依赖注入的用法不同，常见依赖注入有以下 3 种实现：

属性注入
构造方法注入
Setter 注入

这 3 种实现注入的实现代码如下。

a) 属性注入

java

@RestController
public class UserController {
    // 属性注入
    @Autowired
    private UserService userService;

    @RequestMapping("/add")
    public UserInfo add(String username, String password) {
        return userService.add(username, password);
    }
}

b) 构造方法注入

java

@RestController
public class UserController {
    // 构造方法注入
    private UserService userService;

    @Autowired
    public UserController(UserService userService) {
        this.userService = userService;
    }

    @RequestMapping("/add")
    public UserInfo add(String username, String password) {
        return userService.add(username, password);
    }
}

c) Setter 注入

java

@RestController
public class UserController {
    // Setter 注入
    private UserService userService;

    @Autowired
    public void setUserService(UserService userService) {
        this.userService = userService;
    }

    @RequestMapping("/add")
    public UserInfo add(String username, String password) {
        return userService.add(username, password);
    }
}

其中，@Autowired 支持属性注入、构造方法注入和 Setter 注入，而 @Resource 只支持属性注入和 Setter 注入，当使用 @Resource 实现构造方法注入时就会提示以下错误：

当使用 IDEA 专业版在编写依赖注入的代码时，如果注入的是 Mapper 对象，那么使用 @Autowired 编译器会提示报错信息，报错内容如下图所示：

虽然 IDEA 会出现报错信息，但程序是可以正常执行的。然后，我们再将依赖注入的注解更改为 @Resource 就不会出现报错信息了，具体实现如下：

<<<<<<< HEAD

8c2210e86d51175e82ec2bef4137a47c48031487

Spring面经[上] ​

什么是Spring框架 ​

什么是IOC? ​

依赖注入和依赖查找有什么区别? ​

依赖注入和依赖查找? ​

IoC和DI有什么区别? ​

Bean有几种作用域 ​

singleton ​

prototype ​

request ​

session ​

application ​

websocket ​

什么是AOP ​

说说AOP技术实现原理? ​

JDK动态代理和CGLIB有什么区别? ​

动态代理是如何实现的? ​

@Configuration与@Component区别? ​

JDK动态代理和CGLIB有什么区别? ​

单例Bean线程安全吗? ​

单例Bean线程一定不安全吗? ​

Bean有几种注入方式? ​

@Autowired底层是如何实现的? ​

@Autowired和@Resource有什么区别? ​

依赖注入的支持不同 ​

<<<<<<< HEAD ​

Spring面经[上]

什么是Spring框架

什么是IOC?

依赖注入和依赖查找有什么区别?

依赖注入和依赖查找?

IoC和DI有什么区别?

Bean有几种作用域

singleton

prototype

request

session

application

websocket

什么是AOP

说说AOP技术实现原理?

JDK动态代理和CGLIB有什么区别?

动态代理是如何实现的?

@Configuration与@Component区别?

JDK动态代理和CGLIB有什么区别?

单例Bean线程安全吗?

单例Bean线程一定不安全吗?

Bean有几种注入方式?

@Autowired底层是如何实现的?

@Autowired和@Resource有什么区别?

依赖注入的支持不同

<<<<<<< HEAD